Projet PROPRE avec R
1
Présentation générale d’un projet PROPRE
1.1
Qu’est-ce qu’un projet collaboratif PROPRE ?
1.2
Un projet PROPRE est multi-compétences
1.3
Le premier projet PROPRE : {propre.rpls}
1.4
Que contient le présent livre numérique ?
2
Étapes du projet dans l’ordre chronologique
2.1
Mise en place
2.2
Le cycle de développement
DevOps
2.3
Tests utilisateurs et livraisons
I Coordination du projet
3
[coord] Comment lancer le projet ?
3.1
Trouver un consensus lors d’une réunion de démarrage
3.2
Les étapes principales de coordination
4
[coord] Comment coordonner le projet ?
4.1
Communiquer, communiquer, communiquer
4.2
Équipes
4.3
Rôles clés
4.4
Définir un agenda
4.5
Célébrez vos victoires
5
[coord] Les outils de travail
5.1
Outils et moyens de communiquer
5.2
Outils de développement et d’édition
5.3
Utiliser le format
Markdown
pour prendre les notes
6
[coord] Quelles questions se poser sur la gestion des données ?
II Équipe éditoriale
7
[edition] Comment définir ses besoins et le contenu
7.1
Écrire des “User stories” et proposer une trame de publication
7.2
Quels outils utiliser pour partager vos besoins avec les développeurs ?
7.2.1
Etherpad : prendre des notes collaboratives pendant les réunions
7.2.2
git
: Versionner la trame de publication
7.2.3
GitLab Wiki : Stocker les comptes-rendu de réunions et la trame de publication
7.2.4
Rocket Chat : communiquer de manière asynchrone entre éditeurs et avec les développeurs
8
[edition] Suivre le traitement de ses besoins
8.1
Présentation du Kanban et des labels
8.2
Utilisation du Kanban pour le suivi de projet
8.3
Utilisation du Kanban pour la communication
9
[edition] Rédiger et fournir les textes en RMarkdown
9.1
Stratégies d’échange de contenu entre [Dev] et [Ed]
9.2
Le langage Markdown
9.3
Spécificité des stratégies RMarkdown
9.3.1
RStudio, un éditeur de texte accessible
9.3.2
Anatomie d’un RMarkdown
9.3.3
Subtilité RMarkdown
9.4
Participer à l’ajout de textes sur git
10
[edition] Tester, reporter les bugs, valider
10.1
Phase de validation
10.2
Valider les tickets
10.3
Reporter des bugs
10.4
Demander de nouvelles fonctionnalités
11
[edition] Produire, diffuser et communiquer
III Équipe développement
12
[dev] Mettre en place un projet de développement avec RStudio et GitLab
12.1
En résumé : Checklist 1ère issue GitLab
12.2
Mise en place d’un projet sur GitLab
12.3
Gestion des issues avec le
Kanban
12.4
Gérer les utilisateurs et les droits
12.5
Initier le projet R avec RStudio
12.5.1
Créer un projet de package R
12.5.2
Documenter le développement avec
dev_history.R
12.5.3
Documenter les métadonnées du package avec le fichier
DESCRIPTION
12.5.4
S’occuper du versionnement avec
git
12.5.5
Définir un environnement de travail figé avec {renv}
12.5.6
Documenter le dépôt
git
avec un
README
12.5.7
Documenter les modifications du projet avec les
NEWS
12.5.8
Initialiser les tests unitaires
12.5.9
Initialiser l’intégration continue
12.5.10
Dernières vérifications avant premier envoi sur le serveur
12.6
Gestion des branches du
git
:
GitLab-flow
et branches-issues
12.6.1
Présentation d’un
GitLab Flow
complet
12.6.2
Définir le niveau de protection des branches
12.7
Choisir un mode pour les
Merge Requests
12.8
Choisir l’effet des
Merge Requests
sur les
issues
12.9
Documenter le dépôt GitLab pour les nouveaux utilisateurs
12.10
Définir le mode de participation de l’équipe éditoriale
13
[dev] - Créer des tickets et gérer la communication et l’avancement avec un Kanban
13.1
Présentation du Kanban et des labels
13.2
Transformer la liste des demandes du comité éditorial en tickets
13.3
Prioriser et assigner les tickets
13.4
Utilisation du Kanban pour le suivi de projet
13.5
Utilisation du Kanban pour la communication
14
[dev] - Développer en collaboration sur un projet git avec GitLab et RStudio
14.1
Récupérer le projet depuis le serveur GitLab
14.1.1
Gérer les caractères de fin de ligne
14.2
Choisir son ticket entre le Kanban et le
Chat
14.3
Gestion des branches du
git
:
GitLab-flow
et branches-issues
14.3.1
Présentation d’un
GitLab Flow
complet
14.3.2
Comment créer sa branche-issue depuis
“master”
14.4
Rédiger un message de commit informatif
14.5
Comment se maintenir à jour avec la branche
master
14.5.1
Maintenir {renv} à jour
14.6
Développer un package avec la méthode
Rmd first
14.7
Intégrer les modifications à la branche “dev”
14.7.1
Vérification de l’intégration continue
14.7.2
Fusion dans
dev
par les [ChfDev]
14.8
Comment gérer et accepter les MR/PR
14.8.1
Recommendation : le
rebase
14.8.2
Note sur le
cherry-pick
14.8.3
L’autre méthode : le
merge
14.8.4
Comparer les versions de deux branches
14.9
Sauver son mot de passe git dans le Terminal
14.10
Élaguer les branches mortes
14.10.1
Nettoyer les branches sur GitLab
14.10.2
Nettoyer les branches “locales-distantes”
14.10.3
Nettoyer les branches “locales-locales”
15
[dev] Développer un package documenté et testé avec la méthode ‘Rmd first’
15.1
Développer
15.2
Utilisation de {renv} pour les versions de packages R
15.3
Documenter et tester pour les développeurs
15.4
Documenter pour les utilisateurs
16
[dev] Release : Validation - Livraison par les [ChfDev]
16.1
Étapes avant livraison
16.2
Phase de validation
16.3
Choisir un numéro de version pour la livraison
16.4
Livraison
16.5
Documentation de la livraison
17
[dev] Pratiques, trucs et astuces de code avec R
17.1
Gestion des encodages
17.2
Tester la compilation de vignette pendant son développement
17.3
Les notes sur les
globalVariables
à cause du {tidyverse}
17.4
Les choix en data visualisation
17.5
git
en ligne de commande dans le Terminal RStudio
17.5.1
Vi
par défaut
17.5.2
Nano
pour plus d’aisance
18
[dev] Recommandations de rédaction et de développement
18.1
Rmd
18.2
Envoyer ses modifications sur serveur
References
Accompagné par ThinkR
Organisation d’un projet collaboratif de publication PROPRE
References